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(57) ABSTRACT 

A system and method for displaying the current street 
address on the display of a mobile wireless communications 
device. The longitude and latitude of the device is deter- 
mined by a system such as GPS and triangulation. This 
information is appended to the URL of a Web server, and a 
browser contained within the wireless device navigates to 
the server. The server performs reverse geocode processing 
on the longitude and latitude to compute the corresponding 
street address. The street address is then sent to the wireless 
device for display. 

17 Claims, 6 Drawing Sheets 
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SYSTEM AND METHOD FOR DISPLAYING HDML/WML is a markup language intended for use in 

THE LOCATION OF A WIRELESS specifying content and user interfaces for narrow bandwidth 

COMMUNICATIONS DEVICE WIRING A ("narrowband") devices, including cellular phones, pagers, 

UNIVERSAL RESOURCE LOCATOR and personal digital assistants ("PDA"). HDML/WML was 

5 designed with the limitations and constraints of these 
narrowband, small screen devices specifically in mind. 

BACKGROUND OF THE INVENTION Some of these constraints include a smaller display and 

1 Field of the Invention limited user input facilities, a narrowband network connec- 
Tne present invention relates generally to wireless com- tion ***** memorv ™ d computational resources. 

munications and, more particularly, relates to a system and 10 Though HDML syntax is similar to HTML (Hypertext 

method for displaying the location of a wireless communi- Markup Language) syntax, HDML is not a true markup 

cations device. language. It is a set of commands or statements that specifies 

2 Related Art how a narrowband device interacts with a user. HDML 

i . f • , , • . • j • applications display information on the handset display and 

The advent of wireless personal communications devices 1S FK ., , y . J , . A . 4 L J . . 

l i *• • j »t_ * i * *• • -j * specify how the handset responds to user input. The text 

has revolutionized the telecommunications industry. * *. ji * • * «i j * *u n a- i 

^ „ , t - . /((DPC m j presentation and layout area is tailored to the smaller display 

Cellular, personal communications services (PCS ) and r . . i * . , , . A u , , , r , „ 

, * K . , . , t • * area typical to a narrowband device. A card and declc 

other services provide wireless personal communications to / r . , , . . . . c 

, f . j. ._, , 4 L • 4t _ cx= *u organizational structure is used whereby all information is 

businesses and individuals at home, in the office, on the ° . . . t t1 c . « , . u - 

. x , 4 . • , , organized into a collection of screen sized cards, each of 

road, and to any other location the wireless network can ™ f . « , . . . 4 a. t. j * j 

t_ «/* i . t u . , „ 20 which specifies a single interaction between the handset and 

reach. Wireless telephone subscribers no longer must use . v. . . ° - TT ~ WT . 

. „ . . i .u a * * ♦ user. A deck contains one or more cards. HDML supports 

public telephones along the road or wait until returning to , A - , . ,. 4 , . . . Ji r , 

f, , j«- . f i several types of cards, including entry cards, which display 

the home or office to check messages or to return important Jr , „ * & 4 * ■ * * * i/ * 

business calls. Instead, wireless subscribers can carry out a ™ \ 6 ^k! 

. * j l * c *u r * u-i <v cards, which display multiple options from which the user 

day-to-day business from the pnvacy of an automobile, from ' j j- i • ■ » j • • . e 

J . /. .. „ - r , J t . . . 25 can choose one; and display cards, which display informa- 

a remote job site while walkmg along the airport concourse, ^ ^ ^ fe p y rted for 

ac^Me 8 P conmunlcatIons S1 8 nal 15 managing navigation between cards and decks. String 

accessi e. parameterization and state management allow the use of 

Thus, it is no surprise that since the introduction of the stafc model& tQ add parameters to decks . 

cellular telephone service, the number of wireless telephone 30 „, , Tim »f/«Fv*T ff «= • * e -j 

, K j j ■ i t* j * Today, HDML/WML offers an efficient means of provid- 

subsenbers has increased steadily. Today, there are a stag- . Jwa *> k ^ ^ «i i_ ■ n. * * 

u r*i *i u u-u u ins content and services from the Web infrastructure to 

gering number of wireless telephone subscribers whose p , , , " „ , . 

i * »i f r 4 . u~i^ u ^ wireless handheld devices such as cellular phones, pagers, 

ranks are growing rapidly. In fact, many households have , ^ . . , r * r ^ 

, - i . . * . ... and PDAs. Another useful feature associated with some 

multiple wireless telephones in addition to their conven- , . , / , ^ ... 

ii j 1 * • wireless communication devices is the Global Positioning 

tional land line services. 35 „ ^^™„v 1 ^™ < ... . 

„_ . . , . . . . • c System ("GPS"). A GPS receiver in or associated with the 

With a market of this size, there is fierce competition a evice ; communicates wi th a constellation of GPS 

among hardware manufacturers and service providers. In an {q dctcrmine the ^ location of mc device in 

attempt to lure customers, most providers offer handsets . r . , , t ... , , . . r ♦* „ 

. * ^1 * . * £ . ' . u 11 • 1* u* terms of global latitude and longitude. This information may 

with desirable feamres or attributes such as smal s^ejhght be »^ ^ olher s ^ ems such M & 

weight, longer battery life q»eed dial and the hke. Many 40 Howeyer ob ^ Moa - m (erms of ktitude and 

recent addiUons to the marketplace mclude muln-functional ^ k ^ ^ fal , o ^ torof a wMm> 

handsets that even provide pocket organizer functions inte- • / a - 

j . K , *™j * * r ^ communication device, 
grated mto the wireless handset. Most manufacturers, 

however, are still scrambling to add new features to their SUMMARY OF THE INVENTION 

communications devices to snare a portion of this booming 45 

ujjjj^ The present invention uses the existing infrastructure of a 

One way in which new features are added to wireless wirdess HDML/WML browser to send latitude and longi- 

communication devices is by integrating the devices into the mde ^formation from a wireless handset to a remote Web 

Web. Such integration allows the countless services avail- The Web server processes the latitude and longitude 

able through the Web to be extended to wireless communi- 50 and rctums the handsct locatloa for dls P la y m a format lhat 

cations devices. Traditional web pages, however, usually » understandable and usable by the handset operator, 
contain too much information to be presented on the typi- 
cally smaller display of a wireless communication device 



such as a digital cellular telephone. To address this problem 
new Web based programming languages such as the Hand 
held Device Markup Language ("HDML") have been devel 



In one embodiment of the invention, a method for dis- 
playing the location of a wireless handset is provided. The 
method comprises the steps of receiving a request from a 
55 user of the handset to display the handset location; acquiring 
the handset location; sending the handset location from the 



oped to serve the wireless market. In serving the wireless handset to a Web server; processing the handset location to 
market, HDML has evolved and is sometimes called the generate a street address; sending the street address from the 
Wireless Markup Language ("WML"). This language, server to the handset; and displaying the street address on a 
which will be referred to herein as HDML/WML, is part of 60 display of the handset. 

a larger standard called the Wireless Application Protocol In another embodiment of the invention, a method for 
("WAF'). WAP is a result of continuous work to define an displaying the street address of a mobile phone is provided, 
industry wide standard for developing applications over First, a request is received from a user of the handset to 
wireless networks. The WAP forum was formed to create a display the mobile phone location. Next, the current latitude 
global wireless protocol specification that works across 65 and longitude of the mobile phone is acquired and appended 
differing wireless network technology types for adoption by to the URL address of a Web server. A Web browser 
appropriate industry standards bodies. contained within the phone is navigated to the URL address, 
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and the server at the address parses the latitude and longitude FIG. 7 is a flowchart of a method for receiving latitude 

from the URL address and performs reverse geocoding on and longitude information embodied in an information 

the parsed latitude and longitude to generate the street request and returning a street address in response to the 

address of the mobile phone. The street address is sent from request. 

the server to the mobile phone and displayed on the mobile 5 FIG g fc a ^ &am of a handset display de picting a set of 

P hone - HDML/WML interface cards for receiving the street address 

In an additional embodiment of the invention, a method of a OTmmunications dev ice. 
for presenting the current street address of a wireless com- 
munications device on a display of the device is provided. DETAILED DESCRIPTION OF PREFERRED 
The current latitude and longitude of the device is acquired 1Q EMBODIMENTS 
and sent to a Web server. The Web server reverse geocodes 

the latitude and longitude to generate the street address of \ m Introduction and Overview 
the device, and sends the street address from the server to the 

device for display. Th e P rcscnt invention provides a system and method for 

In a further embodiment of the invention, a method for displaying the current location of a wireless communications 

using an Internet browser to display the street address of a 15 device. In response to a request for current location, the 

wireless handset incorporating the browser or to dial a wireless device acquires its current location, typically in 

telephone number is provided. An input is first received from longitude and latitude format, and sends it to a remote server 

a user of the wireless handset. The input comprises either a capable of performing reverse geocoding on the longitude 

location request or a telephone number to be dialed. If the and latitude information. The server performs reverse geoc- 

input is a telephone number, the browser is terminated and 20 fding and generates the corresponding street address, which 

the telephone number is dialed. If the input is a location ^ 10 

request, the current latitude and longitude of the handset is 2 £xa e^^^ 

acquired, and the browser is navigated to a reverse geocod- r 

ing Web server. The server performs reverse geocoding on Before describing the invention in detail, an example 

the latitude and longitude to generate the street address of environment in which the invention can be implemented will 

the handset and sends the street address to the handset for be described. One example environment is a handset or 

display. communication device operating within a wireless cornmu- 

In a still further embodiment of the invention, a wireless nication network such as, for example, a cellular, GSM, PCS 

communications system comprises a wireless handset and a 3Q or radio communication network. One example wireless 

Web server. The handset includes a transceiver for sending communication device (handset) 100 is illustrated in FIG. 1. 

and receiving communications across a wireless communi- Wireless communication devices embodying the present 

cation network and an Internet browser configured to accept invention, however, can be implemented in various configu- 

a user request for the current location of the handset. The rations and architectures. Implementation of the invention is 

request includes the URL address of the Web server. A 35 not dependent on any particular device architecture or 

position determination unit associated with the handset communication network. 

determines the current latitude and longitude of the handset. Handset 100 includes processor 104, speaker 106, display 

The Web server is in communication with the handset over 108, keypad 110, transceiver 122, memory 114, microphone 

the network and receives the latitude and longitude from the nfi^ power source 118 and antenna 120. Handset 100 is 

Internet browser. It performs reverse geocoding on the typically a mobile unit such as a handheld cellular phone or 

latitude and longitude to generate the street address of the an integrated vehicle phone. It is configured to communicate 

handset, and sends the street address to the handset for with other communications devices such as base station 112. 

display. Base station 112 is located within a geographic area known 

These and other aspects and embodiments of the present as a "cell" and handles communications for all mobile units 

invention will be apparent in the following description, 45 within the cell. 

claims and drawings. Processor 104 directs the overall operation of handset 

BRIEF DESCRIPTION OF THE DRAWINGS 10 °* A computer program or set of instructions is typically 

m t coded or otherwise implemented on the processor to enable 

The present invention is described with reference to the ^ ^ to out ^ device operation . As will be 

accompanying drawings, in which like reference numerals ^ described m more detail beloWj ^ kernel or World Wide 

refer to like parts. Web ("Web") browser may be coded into the processor and 

FIG. 1 is a block diagram of a wireless communication used ^ the 0 p Cratm g sys tem for handset 100. Memory 114 

device. interfaces with processor 104 and may store program code 

FIG. 2 is a block diagram of a wireless communication and provide storage space for data useful in executing the 

system according to the present invention. 5S program code and carrying out handset functions. Memory 

FIG. 3 is a flowchart of a method for requesting infor- 114 ma y be implemented as Read Only Memory ("ROM"), 

mation across a wireless network according to the present Random Access Memory ("RAM") or as any other conve- 

invention. nient memory format. The features and functionality of the 

FIG. 4 is a diagram of a handset display depicting a invention described below may be implemented using 
sample set of HDML/WML interface cards for dialing a 60 hardware, software or a combination of hardware and soft- 
telephone number. ware. If implemented as software, the software may run on 

FIG. 5 is a diagram of a handset display depicting a set of processor 104 or be stored in memory 114. 

HDML/WML interface cards for sending local information Transceiver 122 includes a transmitter that transmits 

from a wireless handset to a Web server. voice and data information via antenna 120 to a recipient 

FIG. 6 is a flowchart of a method for sending information 65 communication device (such as base station 112), and a 

across a wireless network to a Web server according to the receiver that receives voice and data information from a 

present invention. transmitting communication device (such as base station 
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112). User interface features include speaker 106, display 
108, keypad 110 and microphone 116. Microphone 116 
accepts voice or other audio information from the user and 
converts this information into electrical signals that can be 
transmitted by transceiver 122. Likewise, speaker 106 con- 
verts electrical signals received by transceiver 122 into 
audio information that can be heard by a user of device 100. 
Display 108 displays information such as call information, 
keypad entry information, signal presence and strength 
information, battery life information, and other useful infor- 
mation. Display 108 preferably takes the form of a liquid 
crystal display ("LCD"), which has low power consumption 
characteristics, but could also be implemented as a light 
emitting diode ("LED") display or any other appropriate 
visual indicator. Keypad U0 typically includes an alphanu- 
meric keypad and special function keys. It may be backlit to 
permit viewing of the keys in low light or dark conditions. 
A flip panel (not shown) may conceal all or a portion of 
keypad 110. 

Power source 118 provides power to device 100. It may 
be implemented with rechargeable batteries, such as NiCad 
or NiMH rechargeable batteries, or with any other suitable 
power source. 

3. Wireless Services Through a Web Server 

FIG. 2 is a block diagram illustrating a wireless commu- 
nication system according to the present invention. The 
communication system provides information to a wireless 
handset based on the location of the device. It includes a 
wireless handset 130 and a hands-free unit 132 incorporating 
a position determination system 134. Handset 130 can be 
implemented in a configuration similar to that of handset 
100 of FIG. 1, or in any other device configuration that is 
capable of communicating with remote locations via a 
wireless communication medium. In the description below, 
"handset** refers to any communication device capable of 
communicating with other devices via a wireless medium. 

Hands-free unit 132 is optionally provided to allow the 
user of handset 130 to communicate in a hands-free mode. 
Hands-free unit 132 may include a microphone and speaker 
to provide handset 130 with speakerphone-like capabilities. 
Such capabilities are particularly desirable where handset 
130 is utilized in an automobile or other mobile situation. In 
one implementation, hands-free unit 132 is configured 
according to conventional industry standards for a "hands- 
free kit". 

As mentioned above, hands-free unit 132 is preferably 
equipped with a position determination system 134 that 
determines the location of hands-free unit 132 and handset 
130. Rjsition determination system 134 could also be 
directly incorporated into handset 130. System 134 deter- 
mines location in terms of parameters such as latitude, 
longitude, height, speed of travel, and other useful location 
or position parameters. In one implementation, position 
determination system 134 uses the Global Positioning Sys- 
tem ("GPS'*) or differential GPS, the operation of which is 
well known to those of ordinary skill in the art. Alternative 
position determination systems, such as triangulation 
systems, may also be used. 

Handset 130 preferably includes both a voice and data 
interface, particularly where position determination system 
134 is incorporated in hands-free unit 132. The voice 
interface provides hands-free operation and speakerphone- 
like capabilities. The data interface allows location infor- 
mation obtained by system 134 to be provided to handset 
130 for transmission over wireless network 140. 
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Handset 130 communicates with other entities via wire- 
less network 140. Network 140 is typically comprised of a 
plurality of base stations that provide relay points for 
communication. Network 140 may be a cellular, PCS, GSM, 

5 or any other wireless communication network. In addition to 
conventional communication with other wired or wireless 
communication devices, as shown in FIG. 2, network 140 
permits communication between handset 130 and data 
servers) 136. When a user requests information, handset 

10 130 provides the location of the handset to server 136 across 
wireless network 140. Server 136 retrieves relevant infor- 
mation from an associated database 138 and conveys the 
information to handset 130 over wireless network 140. The 
information may be displayed on the handset display or 

15 audibly rendered via speech synthesis or prerecorded scripts. 
Although the type of information stored in database 138 is 
virtually limitless, several example applications are pro- 
vided for illustrative purposes. 

In one example application, driving directions to a des- 

20 tination address are provided to handset 130. The handset 
user requests driving directions to the destination, and the 
handset relays the request to server 136 over wireless 
network 140. At the time of the request, the handset location 
is also provided to server 136 to provide a starting point for 

25 the directions. Using the handset location and the destination 
address, server 136 calculates a route and compiles driving 
directions. The driving directions are transmitted to handset 
130 over network 140 and are displayed or audibly rendered 
to the user. In addition to textual driving directions, a map 

30 showing the route may be displayed on the handset display. 
Options such as the shortest possible route, interstate route, 
safest route, most scenic route, etc. may be provided. The 
user's choice of options will dictate the route calculation. 
The options may be stored locally and prompts or scripts 

35 generated in the memory of handset 130. Alternatively, the 
options, prompts and scripts may be stored at server 136 and 
provided to the user via network 140. 

Another example application locates particular types of 
businesses or services in the user's location. Restaurants, gas 

40 stations, hotels and other businesses or services near the 
user's location can be identified and provided to the user. 
Again, the user requests the business or service type vocally 
or via keypad entry. The request is communicated to server 
136 over wireless network 140, along with the user's current 

45 location as determined by the position determination system 
134. Server 136, based on the handset location and user 
request, retrieves and returns relevant information to handset 
130 over network 140. 

Parameter limits or filters may be implemented to refine 

50 the request and selections returned. The user may set a 
location filter, for example, that requires returned selections 
be within a certain maximum number of miles of the user's 
current location. If the user is seeking a restaurant, the user 
may request or be prompted to select parameters that refine 

55 the search results. These parameters may include cuisine 
type (e.g., Italian, French, American, etc.), restaurant type 
(e.g., fast food, casual dining, formal, etc.), price range and 
so on. Additionally, for restaurants, gas stations, motels and 
other businesses, the user may identify a preferred national 

60 or regional chain. Alternatively, the user may have a pref- 
erences profile stored in the Web server 136 that contains 
this information. 

As noted above, the search may be refined (the query 
narrowed) on the user's own initiative or based on system 

65 prompts. If the user simply requests a nearby restaurant, for 
example, server 136 may prompt the user with questions 
about parameters such as those described above. 
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Alternatively, to conserve bandwidth over network 140, 
prompts can be stored locally and made by handset 130 (or 
hands-free unit 132) before the request is sent to server 136. 
In this embodiment, updated scripts and/or prompts may be 
downloaded from server 136 to handset 130. Preferably, 
memory-intensive data such as establishment locations, 
driving directions, etc. are stored in database 138 to mini- 
mize the amount of memory required in handset 130. The 
precise distribution of data storage among these devices will 
be influenced by factors such as available bandwidth, 
memory costs and airtime costs. 

A method for requesting information across network 140 
is illustrated in FIG. 3. In step 202, a user initiates a request 
for information. In step 204, the system determines whether 
the request requires the handset location or position. If 
position information is required, the method proceeds from 
step 204 to step 212, where system 134 acquires the position 
of handset 130. If system 134 is situated in hands-free unit 
132, unit 132 provides the position data to handset 130 for 
transmission to server 136 over wireless network 140 (step 
214). If position information is not required, the method 
proceeds from step 204 directly to step 206. 

In step 206, handset 130 sends the request to server 136 
via wireless network 140. The request includes any position 
data acquired in steps 212-214. The present invention 
provides a novel method for sending the local information 
included in the request using an HDML/WML browser that 
will be described in more detail below. In step 208, server 
136 retrieves the data or information requested from data- 
base 138 and communicates the data to handset 130 over 
network 140. In step 210, the data is displayed or provided 
to the user. 

As described above, scripts or prompts may be provided 
to the user to refine the information request. If the scripts or 
prompts are stored in database 138 (as opposed to local 
storage in handset 130), they are retrieved by server 136 in 
step 208 and provided to the user in step 210. The user's 
answers to the prompts are sent by handset 130 to server 
136, which uses the refined information to retrieve addi- 
tional data or information from database 138, or to further 
refine the user's query. This potentially repetitive process is 
illustrated in FIG. 3 by flow line 222 and the repetition of 
steps 202, 206 and 208. 

4. Sending Local Handset Information to a Web 
Server 

As noted above, the present invention provides a novel 
method for sending local handset information to a Web 
server using a wireless browser. A browser, as is well known 
to those of ordinary skill in the art, is a software application 
that is used to locate and display Web pages. In one 
implementation, an HDML/WML browser is used as the 
handset operating system and handset functions are accessed 
through the browser. The browser presents a list of options 
to the user such as, for example, accessing a phone list, 
accessing an inbox, and so on. In accordance with the 
present invention, one of the presented options is use of a 
Web service that requires local information from the 
handset, such as the location of the handset. The local 
information is sent to a Web server by the browser by 
modifying the phone dialing process such that the local 
information is sent as part of the URL (Uniform Resource 
Locator). 

To provide a backdrop for the present invention, the 
process for instructing the handset to dial a number from a 
launched wireless browser will first be described. First, the 
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user launches the wireless browser. At some point during 
browser operation, the user provides the browser with a 
telephone number to be dialed. The telephone number to be 
dialed will be referred to as the NUMBER input field. The 

5 NUMBER field may be acquired in a variety of ways. Auser 
may directly input the number to be dialed into the handset 
keypad, or may input a unique identifier that enables the 
number to be retrieved from memory. Alternatively, the 
number to be dialed may be acquired via an alphabetical 

10 search of a database of contacts maintained in the handset 
memory. Once the NUMBER field is acquired, the web 
browser displays the number on the handset display and asks 
for affirmation from the user that the displayed number is the 
number that should be dialed. The user may affirm the 

15 displayed number by selecting an "OK" option, pressing an 
"OK" button or the like. Once the user has affirmed the 
number to be dialed, the browser executes a "Call" function 
using the telephone number as the variable input. At this 
point, the handset ends the browser application and initiates 

20 the dialing process. 

As noted above, HDMIVWML uses a "card and deck" 
organizational structure whereby all information is orga- 
nized into a collection of screen sized cards, each of which 
specifies a single interaction between the handset and user. 

25 FIG. 4 depicts a sequence of HDML/WML user interface 
cards 230 and 235 as displayed to the user during the dialing 
process described above. First interface card 230 displays 
the number that the user wants to dial ("858-555-1212") and 
requests affirmation from the user ("OK"). Second interface 

30 card 235 displays the status of handset 100 during the 
connection process as well as the telephone number that the 
handset is attempting to connect with. An example of an 
HDML/WML code section associated with card 230 is set 
forth below: 

35 



<HDML VERSION-3.0> 
<DISPLAY> 

<ACTION TYPE-ACCEPT LABEL-OK TASK-CALL 
40 NUMBER=858-555-1212> 
Dial Number 
<BR>858-555-1212 
</DISPLAY> 
</HDML> 



45 

The first line of code defines the header of the HDML 
deck. All HDML decks must begin with an <HDML> tag 
and end with an </HDML> tag (line 6). The second line of 
code defines the header of the display card. Like HDML 

50 decks, cards require beginning (<DISPLAY>) and ending 
tags (</DISPLAY>). The third line of code defines an action, 
which specifies what the handset should do when the user 
presses a specified function key. The TYPE=ACCEPT por- 
tion identifies the function key, in this case the ACCEPT key, 

55 and the LABEL=OK portion instructs the browser to apply 
an "OK" label to the ACCEPT key, thereby inviting the user 
to press the ACCEPT key in order to proceed. The TASK- 
CALL specifies what the handset should do when the user 
presses the ACCEPT key, in this case, switch the handset to 

60 voice mode and call the number specified in the NUMBER 
option, which is NUMBER=858-555-1212. 

Lines 4 and 5 provide the text that is displayed on the 
handset display (card 230). "Dial Number" is displayed in a 
first text line, and "858-555-1212" is displayed in a second 

65 text line. The <BR>command preceding line 5 instructs the 
browser to start a new line of text. The "OK" text appears 
because of the LABEL=OK portion of line 3. When the 
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handset user presses the ACCEPT button to accept the "OK" carry out the request. Once the server has the local 

option on card 220, the HDML/WML browser executes the information, it will carry out the request and communicate 

"Call" task, using the 858-555-1212 telephone number as a the results to the handset (steps 208 and 210 of FIG. 3). 

variable input. The browser apphcation is terminated and the ^ example of an HDML/WML code section associated 

phone number is dialed !. Ir i this a usnu able to dial 5 with displaying a card 240 (FIG. 5) for the Web service 

a phone number directly from the HDML/WML browser. < twhere m I? „ fa M forth 

The present invention modifies this existing HDML/ 
WML infrastructure to permit local information to be sent 
from the handset to a Web server using the browser. FIG. 6 

is a flowchart illustrating a method 250 for sending local 10 <hdml version=3.o> 

information to a Web server from a wireless handset. In the <display> 

* * * *l j r * £ <ACTTON TYPE-ACCEPT LABEL-OK TASK-CALL 

context of the method for requesting information across a v™\™^o^_ 7a . T, 

. , , ^ An ^ , . „ NUMBER=GPShttp://www. myaladdxn.com/NP?> 

wireless network 140 illustrated in FIG. 3, method 250 service 

would be carried out in step 206. <BR>where am I 

In step 252, the handset user launches the wireless i 5 </DiSPLAY> 
browser application. In an implementation where the 



browser acts as the handset operating system, step 252 may 

occur automatically (without user action). In step 254, the As can be seen, this code section is similar to the code 

user selects either a web service or a telephone number to be section for the dialing of a phone number. The variable 

dialed. The user's selection is entered into the variable input 2 o NUMBER field in the third line, however, is the URL 

portion of the NUMBER=xxxx instruction in the HDML/ address of a server preceded by an information type field. 

WML code set forth above. Where a telephone number to be This will indicate to the handset that rather than terminating 

dialed is selected, the telephone number is inserted into the the browser and dialing the number, it should acquire the 

NUMBER field. Where a web service is selected, a local local information, append it to the URL, and proceed to the 

information type indicator, followed by the URL, is entered 2 s URL (steps 26<V-266 of method 250). The fourth and fifth 

into the number field. "GPS", for example, may be used to lines of code display text associated with the locator service, 

indicate that local information comprising the location of the rather than the dial number function, 

handset is required. Hence, if the user selects a browser ^ , r * t 

option such as "Display my Current Location", the browser 5 * ^turning the Street Address for Display on the 

may enter "GPShttpV/www.myaladdin.com/NP?" into the 30 Handset 

NUMBER field, wherein "GPS" indicates the local in for- Once the server has acquired the local information nec- 

mation type required, and "http:// essary to carry out a request (as described above), the server 

www.myaladdin.comlNP?" is the URL address. performs any necessary processing and supplies a response 

At decision node 256, the handset determines whether the to the handset. In one embodiment, where the service 

user has selected a Web service requiring local information 35 requested is the current location of the handset, latitude and 

or a telephone number to be dialed. In one implementation, longitude information is appended to the URL. In this 

the browser accomplishes this by determining whether the embodiment, described in more detail below, the Web server 

NUMBER variable input has an information type field (i.e., performs a reverse geocoding process on the extracted 

"GPS"). In another implementation, the browser may deter- latitude and longitude data and sends the street address to the 

mine whether the NUMBER variable input includes a URL 40 handset for display. 

address. If the user has selected a number to be dialed, the FIG. 7 depicts a method for converting latitude and 

method proceeds to step 258 and the browser dials the longitude data embedded in a service request from a wireless 

number as described above. The "Call" function is executed handset into a street address for transmission to and display 

to terminate the browser and dial the phone number. on the handset. The method begins where the method of 

If, at node 256, the handset determines that the user has 45 FIG. 6 leaves off: a user has selected a current location 

selected a Web service requiring local information, the option (step 256); local information consisting of the current 

method proceeds to step 260. In step 260, the browser latitude and longitude of the handset has been acquired (step 

acquires the local information necessary to carry out the 258) and appended to the URL (steps 260-262); and the 

request. If the service requested is the user's current browser has navigated to the URL with the appended 

location, for example, the browser will acquire the current so location data. As mentioned above, a position determination 

GPS data from position determination device 134. Other system (134) associated with handset 130 determines the 

types of local information may include user preferences, latitude and longitude of the handset The position determi- 

schedule, contact information and so on. In step 262, the nation system may be part of a hands-free unit (132) 

handset extracts the URL from the service request (the associated with the handset, or it may be directly incorpo- 

NUMBER input). Typically, the LRL will be the address of 55 rated into handset 130. It may use GPS or a suitable 

a Web server that will carry out the information request. The alternative, such as a triangulation system, 

local information acquired by the browser is appended to the In step 270 (FIG. 7), the server at the destination URL 

URL address in step 264 and, in step 266, the handset receives the service request. In step 272, the server parses 

instructs the browser to go to the URL address rather than out the longitude and latitude information that was appended 

terminating the browser and dialing the number in the 60 to the URL in the service request. The URL address with 

NUMBER field. Where the handset location has been local information appended may be in a form such as, for 

requested, for example, the URL address with local infor- example, "http:// myaladdin.com/NP?long=l 11.1111 &lat= 

mation appended may be "http:// myaladdin.comnNP?long= 222.2222&time=<string(URL encoding format)>'\ After the 

111.1 111 &lat= 222. 2222&time=<string(URL encoding longitude and latitude data is parsed, the Web server per- 

format)>". Hence, the browser is able to proceed to the 65 forms a reverse geooode process (step 274) to determine the 

server addressed by the URL and provide the server with the corresponding street address for the latitude and longitude, 

local information (appended to the URL) that is necessary to Reverse geocode processes by a street address is obtained 
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from latitude and longitude data are well known to those of 
ordinary skill in the art. In an alternative embodiment, the 
Web server may send the latitude and longitude data to a 
separate, independent reverse geocode server (not pictured) 
for processing. This outsourcing of the reverse geocode 
processing would be incorporated in step 274 of FIG. 7. 
Once the Web server has the street address corresponding to 
the latitude and longitude data, it is sent to the handset that 
initiated the request (step 276) and the handset displays the 
address to the user (step 278). 

FIG. 8 depicts a sequence of HDML/WML user interface 
cards 280 and 285 that might be displayed on the handset 
during the street address location service. Card 280 allows 
the user to select the "Where am I" service by selecting 
"OK" to initiate the service. Once the user has selected 
"OK w , the handset proceeds to obtain latitude and longitude 
data and appends it to a service request as described above. 
This information is sent to an appropriate server and reverse 
geocoded to a street address that is sent to the handset. Card 
285 depicts the display of the street address as seen by the 
user, along with an "OK" prompt to proceed. It should also 
be noted that, if desired, the raw latitude and longitude data 
(card 245 of FIG. 5) may be displayed to the user while the 
street address is being obtained by the server (after card 280 
but before card 285). 

The system and method described above may be imple- 
mented as computer programs, software or hardware or a 
combination of hardware and software, and may be imple- 
mented in a computing system having one or more proces- 
sors. The HDML/WML code that controls the wireless web 
browser, for example, may be coded in processor 104 or 
stored in memory 114. Alternatively, the program or portions 
of it could be stored on server 136 and downloaded to 
handset 130 as needed. 

Various embodiments of a system and method for sending 
local information from a wireless communications device to 
a web server have been described herein. These embodi- 
ments are presented for exemplary purposes only, however, 
and are not intended to limit the scope of the invention, 
which is defined by the following claims and their equiva- 
lents. 

What is claimed is: 

1. A method for displaying a street address associated with 
a wireless handset including a browser comprising: 

receiving a request from a user of the handset to display 

a street address corresponding to a handset location; 
acquiring the handset location; 

appending data indicative of the acquired handset location 

to a URL address of a Web server; 
sending data indicative of the handset location from the 

handset to the Web server by navigating to the Web 

server using the URL address and browser; 
processing the handset location to generate the street 

address; 

sending data indicative of the street address from the Web 

server to the handset; and 
displaying the street address on a display of the handset. 

2. A method as claimed in claim 1, wherein the handset 
location is acquired as latitude and longitude by a GPS unit 
associated with the handset. 

3. A method as claimed in claim 1, wherein the handset 
location is acquired as latitude and longitude by triangula- 
tion. 

4. A method as claimed in claim 1, wherein the Web server 
extracts the handset location from the URL address and 
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performs reverse geocoding on the extracted handset loca- 
tion to generate the street address. 

5. A method as claimed in claim 1, wherein the server 
performs reverse geocoding on the handset location to 

5 generate the street address. 

6. A method as claimed in claim 1, wherein the street 
address is displayed on the display as part of a HDML/WML 
user interface card. 

7. A method for displaying a street address associated with 
10 a mobile communication device comprising: 

acquiring a current latitude and longitude of the mobile 

communication device; 
appending data indicative of the acquired latitude and 
longitude to the URL address of a Web server, and 
15 navigating a browser contained within the mobile com- 
munication device to the URL address; 
parsing the data indicative of the latitude and longitude 
from the URL address at the Web server and perform- 
ing reverse geocoding on the parsed latitude and lon- 
20 gitude data to generate the street address; 

sending data indicative of the street address from the Web 

server to the mobile communication device; and 
displaying the street address using the mobile communi- 
25 cation device. 

8. A method for presenting the current street address of a 
wireless communications device including a wireless 
browser on a display of the device comprising: 

acquiring the current latitude and longitude of the device; 
30 activating the wireless browser; 

appending data indicative of the latitude and longitude of 

the device to a URL address of a Web server; 
sending the data indicative of the latitude and longitude to 
the Web server using the wireless browser; 
3S reverse geocoding the latitude and longitude data at the 
Web server to generate the street address of the device; 
sending data indicative of the street address from the Web 
server to the device; and 
^ presenting the street address on the display of the device. 

9. A method as claimed in claim 8, wherein the latitude 
and longitude is acquired from a position determination 
system selected from a group consisting of a GPS system 
and a tri angulation system. 

45 10. A method for using an Internet browser in a first mode 
to display the street address of a wireless handset incorpo- 
rating the browser and to dial a telephone number in a 
second mode, said method comprising: 

receiving an input from a user of the wireless handset, 
50 wherein the input comprises either a location request or 
a telephone number to be dialed; 
determining whether the input comprises a location 

request or a telephone number; and 
if the input is a telephone number, terminating the browser 
55 and dialing the telephone number in the second mode; 
and 

if the input is a location request, acquiring the current 
latitude and longitude of the handset, navigating the 
browser to a reverse geocoding Web server, performing 
60 geocoding on the latitude and longitude to generate the 
street address of the handset, and sending the street 
address to the handset for display on the handset 
display in the first mode. 

11. A method as claimed in claim 10, wherein the browser 
65 is an HDML/WML browser. 

12. A method as claimed in claim 10 wherein if the input 
is a telephone number, the telephone number is inserted into 
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a NUMBER field following an HDML/WML CALL 
command, and if the input is a location request, a location 
request indicator and the URL address of the Web server is 
inserted into a NUMBER field following the HDML/WML 
CALL command. 5 

13. A method as claimed in claim 12, wherein said 
determining step comprises determining whether the NUM- 
BER field includes a location request indicator. 

14. A method as claimed in claim 12, wherein said 
determining step comprises determining whether the NUM- 10 
BER field includes a URL address. 

15. A method as claimed in claim 12, wherein if the input 
is a location request, the method comprises extracting the 
URL address from the NUMBER field and appending the 
latitude and longitude to the URL address, and navigating 15 
the browser to the URL address. 

16. A method as claimed in claim 12, wherein the location 
request indicator is "GPS", and wherein the latitude and 
longitude is acquired from a GPS receiver. 
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17. A wireless communications system comprising: 
a wireless handset comprising a transceiver for sending 
and receiving communications across a wireless com- 
munication network; an Internet browser configured to 
accept a user request for the current location of the 
handset, wherein the request includes a URL address; 
and a position determination unit for determining the 
current latitude and longitude of the handset in 
response to the user request; and 
a Web server located at the URL address contained in the 
user request and in communication with the handset 
over the network, the Web server receiving the latitude 
and longitude from the Internet browser, performing 
reverse geocoding on the latitude and longitude to 
generate the street address of the handset, and sending 
the street address to the handset for display. 
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